条件付きGET Request
clientやProxyではcacheをするが、TTLが切れた時にどうするか？という話 色々ある
table:_
versionを使って比較 最終更新日を使って比較
Range Headerと併用する用の条件付きreqのheader
他の4つとはちょっとグループが異なるmrsekut.icon
clientやProxyではcacheをするが、TTLが切れた時にどうするか？という話 cacheを破棄し、新しくOriginからデータを丸ごと再取得する
TTLは切れているが古くて役立たないのかどうかを、Originに問い合わせて確認する
条件付きGet Requestは後者に関する話である
有効期限が切れていても(stale)、内容が古くなっているとは限らない
もし古くなっていなかった場合、再取得するとその分のtrafficが無駄になる
内容が古くなっているかどうかを確認し、古くなっているなら再取得すれば良い
この「古くなっているかどうかをOriginに問い合わせるrequest」のことを条件付きGet Requestと呼ぶ
条件付きGet Requestを受け取ったserverは以下のような操作を行う
受け取ったrequestを読んで、そのresouceが古くなっているかどうかを検証する
検証した結果、
resource自体は返さない
古くなっていたら、resouceを乗せて、200 OKで返す serverはどうやって、resouceが古くなっているかどうかを検証するのか？
(条件付きGet Requestとして使われるかどうかに関わらず、事前に、)Server側がresouceの返却時に何かしらの比較するための値を含めておけば良い
比較する値(検証子)には2種類ある
resourceにversionを振って比較する
更新されるとversionも更新する
responseのETag headerにversionを付与しておく resouceの最終更新日を比較する
これらのいずれかを使用すれば古くなっているかどうかの検証ができる
staleなcacheがある状態で、同じresourceをOriginから取得するためのrequestを送る際に、Browserは条件付きGet Requestを送る
条件付きRequestに、headerを指定することで、上の2つのどちらの検証子を使って検証するかを選択できる
↑これは、説明のためにこう書いたが、
そんなことはほぼない？
参考